The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
1. Description of the Related Art
In computer networks, it is common to collect information about network traffic flow from the network elements involved in the processing of the traffic flow. For example, a network router may export flow information to a collector configured to collect the information and to provide network utilization statistics. In many networks, the communications between the network router and the collector run on transport connections over congestion-controlled transport protocols in order to reduce the impact of network flow information collection on the overall throughput of the network.
The most common congestion-controlled transport protocol used in networks, Transmission Control Protocol (TCP), is connection-oriented endpoint-to-endpoint protocol that does not allow for sharing the transport connection across several logical connection endpoints in a multi-processor platform. However, some network elements comprise one Route Processor and multiple Line Card interfaces. In such network element, each of the Route Processor and the Line Cards are operatively connected to the network and can independently transmit data packets, but only the Route Processor is capable of maintaining the transport connections state information for the network element. The Line Card processors can transmit over the transport connections, but do not have direct access to the data structures that hold the state information of the transport connections.
Consequently, the Line Card processors cannot independently generate packets of network flow information for transmission on these transport connections, especially where the transport connections run over a transport protocol that does not allow for sharing the connection, such as TCP. Furthermore, since the network element provides only for very limited communications between the Route Processor and the Line Card processors, the Line Card processors cannot submit their network flow information to the Route Processor for transmission over the transport connection to the collector.
In some network elements, each Line Card processor is capable of maintaining its own transport connection. A collector connected to such network element for the purpose of collecting network flow information, however, may not be interested in network flow information for each separate card, but instead may only need to know the total network flow information for the network element. In such cases, the collector needs to share, with all the processors in the network element, the same transport connection for transferring network flow information in order to reduce the overhead associated with multiple connections. However, if the transport connection is established over TCP, it is not possible for the Route Processor and all the Line Card processors to share the connection.
Use of other congestion-controlled transport protocols, such as Stream Control Transmission Protocol (SCTP) and Datagram Congestion Control Protocol (DCCP), presents the same problem as the use of TCP described above when these other congestion-controlled transport protocols are used over transport connections between collectors and network elements for the purpose of collecting network flow information.
2. Congestion Control Transport Protocols
2.1 Brief Overview of SCTP
SCTP is a general-purpose transport protocol for message-oriented applications that is designed by the Internet Engineering Task Force (IETF) SIGTRAN working group, which released the SCTP standard draft document RFC2960 in October 2000. SCTP provides support for multi-homed hosts, and can be used as the transport protocol for upper-layer applications that require monitoring and detection of loss of session. The computer system hosts communicating over an SCTP transport connection are usually represented by the so-called SCTP endpoints. An SCTP endpoint is the logical sender/receiver of SCTP packets. An SCTP endpoint is associated with a transport address, which is defined by a Network Layer address, a Transport Layer protocol and a Transport Layer port number. For example, in the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the Transport Layer protocol). According to the standard SCTP specification, each message sent from one SCTP endpoint to another must be acknowledged by the receiving SCTP endpoint.
An SCTP association is a protocol relationship between SCTP endpoints, and is composed of the two SCTP endpoints and the protocol state information. The protocol state information includes, among other parameters, one or more verification tags, a set of transmission sequence numbers, and a set of stream sequence numbers. An SCTP association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints cannot have more than one SCTP association between them at any given time.
The data units transported over an SCTP transport connection are referred to as SCTP packets. If SCTP runs over Internet Protocol (IP), an SCTP packet forms the payload of an IP packet. An SCTP packet is composed of a common header and one or more chunks. The common header contains fields for a source port number, a destination port number, a verification tag, and a checksum. The source port numbers and the destination port numbers are used for the identification of an SCTP association. SCTP uses the same port concept used by TCP and the User Datagram Protocol (UDP). The verification tag is a randomly generated value that is SCTP association-specific, and is exchanged between the SCTP endpoints at the SCTP association startup. The verification tag serves as a key that allows a receiver to verify that the SCTP packet belongs to the current SCTP association. The checksum is used for the detection of transmission errors.
A chunk is a unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content. A chunk header includes a chunk type field, used to distinguish upper-layer application data chunks and different types of control chunks, chunk flag field for chunk specific flags, and a chunk length field. The chunk-specific content occupies the rest of the chunk, and is represented as a value field that contains the actual payload of the chunk. A Transmission Sequence Number (TSN) is attached to each chunk containing upper-layer application data to permit the receiving SCTP endpoint to acknowledge the receipt of the chunk and to detect duplicate deliveries. The TSN is a 32-bit sequence number maintained internally by the SCTP stack.
SCTP supports different streams of messages within one SCTP association. A message is a unit of data in a chunk sent by an upper-layer application over the SCTP association from one SCTP endpoint to another. A stream is a uni-directional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all data messages are delivered in sequence unless out-of-order delivery is requested by the upper-layer application. A 16-bit sequence number, called the Stream Sequence Number (SSN), is associated with each stream, and is maintained internally by the SCTP stack to ensure sequenced delivery of the data messages within a given stream to the upper-layer application. One SSN is attached to each data message sent or received by the upper-layer application.
2.2 Brief Overview of Partial Reliability SCTP (PR-SCTP)
Partial Reliability SCTP (PR-SCTP) is an extension of SCTP in which the strict message reliability requirement is relaxed. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper-layer application or protocol. When messages are transmitted over a PR-SCTP association from one endpoint to another, the sending endpoint may choose to abandon, or skip, messages with TSN numbers that have not been acknowledged by the receiving endpoint based on some criteria such as time outstanding, available memory, or other appropriate criteria. No further attempt to retransmit messages with abandoned TSN numbers will be made by the sending endpoint.
The PR-SCTP extension provides a Forward-TSN-Supported parameter for the INIT and INIT-ACK chunks, and a FORWARD-TSN chunk type. During the establishment of an SCTP association, the Forward-TSN-Supported parameter is used in the INIT and/or INIT-ACK chunks to indicate that the endpoint sending the INIT or INIT-ACK chunk is able to support the FORWARD-TSN chunk. The FORWARD-TSN chunk is used by the sending endpoint to instruct the receiving endpoint to adjust its cumulative received TSN point forward because some missing TSNs are associated with DATA chunks that will not be retransmitted by the sending endpoint. The FORWARD-TSN chunk thus indicates that the receiving endpoint should move its cumulative TSN acknowledgement point forward (possibly skipping past one or more DATA chunks that may not yet have been received and/or acknowledged.) The FORWARD-TSN chunk includes a New Cumulative TSN field, which holds a new cumulative TSN value. The new cumulative TSN value is used by the receiving endpoint to skip/abandon waiting on any missing messages with TSNs smaller than or equal to the new cumulative TSN value. The receiving endpoint thus sets its acknowledgment point to that value as if it had actually received all the data up to the new cumulative TSN number.
2.3 Brief Overview of DCCP
DCCP is a new transport protocol being designed by the IETF primarily to replace UDP as the transport protocol for real-time traffic while providing congestion control capabilities. A draft describing DCCP is draft-ietf-dccp-spec-09.txt released by IETF in November 2004.
DCCP provides for unreliable flow of datagrams with acknowledgements. Thus, a DCCP connection includes data traffic as well as acknowledgement traffic. Acknowledgements inform a sender whether its packets arrived, and whether they were marked for end-to-end congestion control. Acknowledgements are transmitted as reliably as the congestion control mechanism in use requires, possibly completely reliably. A DCCP connection runs between DCCP endpoints that are the logical receivers/senders of DCCP traffic.
The unit of data transmitted over a DCCP connection is called a DCCP packet. A DCCP packet includes a packet header and an application data (payload) portion. The DCCP packet header includes, among other fields, a Source Port field, a Destination Port field, a Type field, and a Sequence Number field. The Source Port and the Destination Port fields identify the DCCP connection and are used in the same manner as in TCP and UDP. The Type field specifies the type of the DCCP packet. There are ten DCCP packet types defined in the DCCP specification: DCCP-Request (type value 0), DCCP-Response (type value 0x1), DCCP-Data (type value 0x2), DCCP-Ack (type value 0x3), DCCP-DataAck (type value 0x4), DCCP-CloseReq (type value 0x5), DCCP-Close (type value 0x6), DCCP-Reset (type value 0x7), DCCP-Sync (type value 0x8), and DCCP-SyncAck (type value 0x9).
The Sequence Number field uniquely identifies the DCCP packet in the sequence of all packets a DCCP endpoint sends on the DCCP connection. The Sequence Number increases by one with every packet the endpoint sends, including packets that do not carry application data, such as a DCCP-Ack packet. The Sequence Number field for a source endpoint is initialized by a DCCP-Request or a DCCP-Response packet upon the establishment of the DCCP connection. The DCCP-Sync and DCCP-SyncAck packets are used to synchronize the DCCP endpoints after detected loss of DCCP packets or after endpoint failure. Both the DCCP-Sync and the DCCP-SyncAck packets include an Acknowledgement Number field that holds the next valid Sequence Number for the endpoint that sends the DCCP-Sync or the DCCP-SyncAck. For example, if a source DCCP endpoint detects a burst of packet loss, the source DCCP endpoint sends to the destination DCCP endpoint a DCCP-Sync packet that includes its current Sequence Number in the Acknowledgement Number field. Upon receipt of the DCCP-Sync packet, the destination DCCP endpoint recovers the current Sequence Number of the source DCCP endpoint, and immediately sends to the source DCCP endpoint a DCCP-SyncAck packet that includes in the Acknowledgement Number field the destination DCCP endpoint's current Sequence Number. In this manner, each DCCP endpoints knows the Sequence Number of the next DCCP packet expected from the other endpoint in the DCCP connection.
Based on the foregoing, a technique for sharing a transport connection across a host having two or more processors that exchange limited inter-process communications is desired. In particular, there is a clear need for a technique for sharing a transport connection established over a congestion control transport protocol, such as SCTP or DCCP.